Standard permissions model

The Standard Model (Model Application 6.0) introduces a user management model out-of-the-box with a base set of predefined roles and permissions governing access to advanced and administrator functionality, as well as access to fields containing sensitive data and personally identifiable information (PII), such as personal address fields and email fields.

Tip: Details about the Axiell Collections Model Application, including identifying which version is running in your environment, can be found here. Full details about the Standard Model (Model Application 6.0) can be found here.

With the introduction of the Standard Model all new implementations of Axiell Collections include a standard permissions model out-of-the-box and, where appropriate, the base set of roles / permissions has already been applied to application objects; for example, the source.email (se) field in acquisition.inf already has read access rights for the PII reader role, write access for the PII writer role, full access for the Data administrator and no access rights for everybody else.

This approach simplifies the permissions model, tightens security by requiring users to be a member of at least one predefined role in order to access Axiell Collections, and eliminates the need to build a permissions model from the ground up as has been the case in the past.

It is anticipated that most roles already defined in systems that upgrade to the Standard Model will map to an equivalent in the standard permissions model. And, if necessary, custom roles can of course be added.

Note: The method for assigning users to roles in Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. is unchanged (and Application Administrators with access to this tool will continue to use it). It is anticipated however that a user access rights management tool will be made available in Axiell Collections itself in a future release, further decreasing reliance on Axiell Designer for user and permissions management.

The roles and permissions defined in the standard permissions model are:

Note: Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.

As the bottom row in the image above makes clear, a user cannot access Axiell Collections unless they are assigned to a role. The following is a summary of permissions assigned to each group:

Active directory / Collections role	Details
Data reader / data_reader	A Data reader: can view but not edit records in most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. ; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.. If a Data reader should have permission to view PII, the user must ALSO be assigned the PII reader role.
PII reader / pii_reader	This role is assigned to users with the Data reader role who should ALSO be able to view PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data writer / data_writer	A Data writer: can view records in most data sources and can edit those records; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.; cannot delete records. If a Data writer should have permission to view PII, the user must ALSO be assigned to the PII writer role. Note: A Data writer does not have the import or search and replace permissions.
PII writer / pii_writer	This role is assigned to users with the Data writer role who should ALSO be able to view and edit PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data administrator / data_manager	A Data administrator has super-user access and: can access all data sources (including Occurrence defaults), but not all administration data sources (such as System lists); can view, edit, and delete records; can view and edit all PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields; can import data and perform search and replace.
App administrator / $ADMIN	The $ADMIN role is assigned to Application Administrators, providing full access rights and administration control. Application Administrators can access all data sources. Permissions include: view, edit, delete, import, search and replace; unlocking read-only records for editing. Also have access to tools such as Purging saved searches; restoring records using Journal Maintenance, editing record level security on records, etc.
api_svcc_account	This role is intended for the API (not users) and gives view access to relevant data sources (Catalogue, Persons and institutions, etc.), but not to PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields.

Related Topics